A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
Storage of information on the disk array is preferably implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of disk space. The disks within a volume are typically organized as one or more groups, wherein each group may be operated as a Redundant Array of Independent (or Inexpensive) Disks (RAID). Most RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate storing of redundant information (parity) with respect to the striped data. The physical disks of each RAID group may include disks configured to store striped data (i.e., data disks) and disks configured to store parity for the data (i.e., parity disks). The parity may thereafter be retrieved to enable recovery of data lost when a disk fails. The term “RAID” and its various implementations are well-known and disclosed in A Case for Redundant Arrays of Inexpensive Disks (RAID), by D. A. Patterson, G. A. Gibson and R. H. Katz, Proceedings of the International Conference on Management of Data (SIGMOD), June 1988.
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on the disks as a hierarchical structure of directories, files and blocks. For example, each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are organized within a volume block number (vbn) space that is maintained by the file system. The file system organizes the data blocks within the vbn space as a “logical volume”; each logical volume may be, although is not necessarily, associated with its own file system. The file system typically consists of a contiguous range of vbns from zero to n, for a file system of size n−1 blocks.
The storage operating system may further implement a storage module, such as a RAID system, that manages the storage and retrieval of the information to and from the disks in accordance with input/output (I/O) operations. The RAID system is also responsible for parity operations in the storage system. Note that the file system only “sees” the data disks within its vbn space; the parity disks are “hidden” from the file system and, thus, are only visible to the RAID system. The RAID system typically organizes the RAID groups into one large “physical” disk (i.e., a physical volume), such that the disk blocks are concatenated across all disks of all RAID groups. The logical volume maintained by the file system is then “disposed over” (spread over) the physical volume maintained by the RAID system.
The storage system may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access the directories, files and blocks stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. Each client may request the services of the file system by issuing file system protocol messages (in the form of packets) to the storage system over the network. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS) and the Network File System (NFS) protocols, the utility of the storage system is enhanced.
The file system executing on the storage system may implement data containers, such as aggregates, which enable the use of flexible (or virtual) volumes. Aggregates are described in U.S. patent application Ser. No. 10/836,817, now issued as U.S. Pat. No. 7,409,494 on Aug. 5, 2008, entitled EXTENSION OF WRITE ANYWHERE FILE SYSTEM LAYOUT, by John Edwards et al., the contents of which are hereby incorporated by reference. Illustratively, a file system layout apportions an underlying physical volume into one or more data containers, such as flexible volumes, of the storage system. The underlying physical volume is another data container, such as an aggregate, comprising one or more groups of disks, such as RAID groups, of the storage system. The aggregate has its own physical volume block number (pvbn) space and maintains metadata, such as block allocation structures, within that pvbn space. Each flexible volume has its own virtual volume block number (vvbn) space and maintains metadata, such as block allocation structures, within that vvbn space.
The storage system may further implement virtual disk objects (vdisks) that are exported to clients as logical unit numbers (luns) to enable the storage system to service both Network Attached Storage (NAS) and Storage Area Network (SAN) environments. One example of such vdisks is described in U.S. patent application Ser. No. 10/216,453, now issued as U.S. Pat. No. 7,107,385, on Sep. 12, 2006, entitled STORAGE VIRTUALIZATION BY LAYERING VIRTUAL DISK OBJECTS ON A FILE SYSTEM, by Vijayan Rajan, et al., the contents of which are hereby incorporated by reference.
A number of disadvantages may arise in storage systems utilizing aggregates to store luns that are exported to clients. An administrator may desire to move a lun from one aggregate to another due to, e.g., load balancing, lack of storage space, etc. Migration of a lun from one aggregate (e.g., a source aggregate) to another (e.g., a destination aggregate) typically requires that the lun be unmounted which, in turn, requires suspension of all data access requests directed to the lun. The lun is then copied from the source aggregate to the destination aggregate before data access requests are restored. The time required to copy the lun may be substantial, especially if the lun is large, e.g., hundreds of gigabytes. Thus, during lun migration, clients are not able to access the lun via data access requests. In a modern IT environment, lack of client access to data for potentially tens of minutes (or hours) is generally unacceptable.